This was recently posted on comp.security.unix. - Paul "Shag" Walmsley <ccshag@cclabs.missouri.edu> "The only difference between myself and a madman is that I am not mad." - Salvador Dali ---------- Forwarded message ---------- Path: golf!zombie.ncsc.mil!paladin.american.edu!gatech!howland.reston.ans.net!pipex!uunet!zib-berlin.de!informatik.tu-muenchen.de!lrz-muenchen.de!news.informatik.uni-muenchen.de!malaka!lopatic From: lopatic@malaka.dbs.informatik.uni-muenchen.de (Thomas Lopatic) Newsgroups: comp.security.unix Subject: HP-UX 9.x: /usr/lib/expreserve creates files anywhere Date: 19 Dec 94 13:17:22 GMT Organization: Institut fuer Informatik der Universitaet Muenchen Lines: 40 Message-ID: <lopatic.787843042@malaka> NNTP-Posting-Host: malaka.dbs.informatik.uni-muenchen.de X-Newsreader: NN version 6.5.0 (NOV) Hello everyone, I've found this bug to exist on HP-UX 9.01 and 9.05. By creating a symlink in /usr/preserve which points to a non-existing file, /usr/lib/expreserve can be tricked into creating a file anywhere on a local file system. The file will be owned by the invoking user. As far as I can judge, this is because expreserve uses stat() to check, whether the file already exists. Since stat() follows links, a stat on a symlink pointing to a non-existing file will fail. Thus, expreserve happily creates the file the symlink points to. Existing files cannot be written over with this method. But there's another thing. The expreserve program uses chown() after the file has been creat()ed. This opens a small window for a race-condition. You have to manage to remove the newly created file before it is chown()ed and replace it by a link to something you'd like to chown(). I haven't managed yet to exploit this race condition. (I've used something along the lines of 'while (unlink (...) < 0); symlink (...);' in a short C program.) I'm told that the expreserve bug mentioned in the CERT advisories was caused by a wrong file name argument being passed to stat(). So this new bug might also be present on different platforms which have already been patched to correct the old bug. Since we only run HPs, I don't have any means of verifying this. These bugs can be exploited because /usr/preserve is writeable for everyone. I can't see why it has to be mode 0777, since expreserve is suid to root, as is exrecover. So I've changed the mode of /usr/preserve to 0755. Does this restrict the functionality in any way? If not, I recommend everyone to change the mode of /usr/preserve to 0755 until patches are available. I notified HP and CERT to weeks ago, so patches should be out 'real soon now'. :) -Thomas -- Thomas Lopatic lopatic@informatik.uni-muenchen.de -- - Paul "Shag" Walmsley <ccshag@cclabs.missouri.edu> "The only difference between myself and a madman is that I am not mad." - Salvador Dali